1. Field of the Invention
The present invention relates to systems and methods for maintaining the proper informational status of system architecture under control of an NMS. More particularly, the present invention relates to systems and methods for maintaining and updating the informational status of components within an electronic architecture by keeping track of EMS class object references relating to the components in “real time”.
2. Background of the Invention
In the increasingly sophisticated field of electronic communication, particularly between electronic systems or machines, the TL-1 line protocol has remained a common industry standard. TL-1 lines are used as a communication medium between different electronic systems or machines, particularly in Internet—and telecommunication—related systems. However, TL-1 commands are typically very specific and limited to the type of systems or machines that utilize such lines. For example, each distinct system component may require its own unique TL-1 commands or inputs that take into account the specifics of the particular component.
Such a need for detailed characteristics makes use of TL-1 commands generally complicated and time-consuming. Further, TL-1 commands used by different system components make it difficult for the components to communicate with one another, even though all use the general TL-1 command protocol. Finally, much detail is required to determine the specific programming characteristics of each hardware component that is being connected with a given TL-1 line. Thus, although ubiquitously used, TL-1 lines have a number of limiting characteristics.
One of the most limiting characteristics of a TL-1 line is that it does not allow for efficient communication between interconnected hardware. For example, if a change is made in a downstream component of an electronic system, it would be very difficult for an upstream component to receive “real-time” information about that specific downstream change. Typically, when a downstream change is currently made to, for example, a component of a system, such change is communicated to an upstream programmer by the person who has made such a change in the downstream component. Such a requirement for the person who creates changes to communicate them “manually” to upstream programmers is inefficient and prone to errors, such as when the person forgets to relay such information to upstream programmers.
As a further non-limiting example, if an electronic switch or card is changed in a downstream component of an electronic network, TL-1 lines connecting the series of network components to an upstream programmer would not efficiently allow the programmer to be cognizant of the change. Such a programmer may receive some indication that a change was made in that specific downstream component if the programmer sends a specific command related to that changed component and the component responds, because of the change, in a way that the programmer was not expecting. This conventional “reactive” method of determining changes downstream is inefficient and prone to errors, particularly when the upstream programmer is not aware of the downstream changes.
Further, in order to effectively communicate with components under the control of a given EMS, an upstream NMS needs to create and store unique EMS class object references that relate to each component under the control of the particular EMS. Each such unique EMS class object reference identifies a specific component within an electronic architecture. When there is an upgrade in EMS or an update in EMS based upon any of the components within the EMS control, such unique EMS class object references will also change. If NMS is not made aware of such changes in unique EMS class object references in its memory, NMS will not be able to communicate to EMS with commands relating to the components of interest whose EMS class object references should have been updated in NMS memory.
Thus, there is a need for systems or methods that automatically update the status of a system architecture as it changes in “real time” in an effective and efficient manner. Additionally, there is a further need for a central processing center to receive all the information from downstream components, and to reform the information into a universal language that is understandable by an upstream component. To that end, there is a need for an automated process that keeps track of any system component changes that have occurred, including system component upgrades and name changes, and relays information relating to EMS class object reference updates to upstream NMS in real time.